Nautilus 1992 July/Nautilus-3-8/Nautilus-3-8.bin/Tools & Utilities/Techy Stuff/Doco ƒ/CSMP ƒ/CSMP-V1-096.TXT

Text File | 1992-06-30 | 44.7 KB | 1,211 lines

C.S.M.P. Digest             Wed, 27 May 92       Volume 1 : Issue 96

Today's Topics:

    Mac programming--where, how to start?
    cancellation (was Re: MF scrap && DialogSelect crash)
    AppleTalk, games, speed...
    General SCSI / CDROM info needed...
    How do you do a simple output window in MacApp?
    Datagloves
    CountAppFiles doesn't work
    TCL Mailing List?
    Weird problem with TEIdle/Blinking cursor
    Color picts drawing in B$W. HELP!


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.  The last several issues of the digest are available from
sumex-aim.stanford.edu as well.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The digest is a collection of articles from the internet newsgroup comp.sys.
mac.programmer.  It is designed for people who read c.s.m.p. semi-regularly
and want an archive of the discussions.  If you don't know what a newsgroup
is, you probably don't have access to it.  Ask your systems administrator(s)
for details.  (This means you can't post questions to the digest.)

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Jose Hulse)
Subject: Mac programming--where, how to start?
Date: 20 Apr 92 19:22:31 GMT
Organization: Lewis & Clark College, Portland OR


Hello all,

Here's the scoop--I'm a fairly proficient Mac user, but I have no idea
about programming.  About as adventurous as I get is to perform simple
ResEdit hacks that someone else has come up with.

But I want to program--especially in the fields of foreign language soft-
ware and games.  How do I start learning?  I took "intro to computers"
way back in college (I'm 31 now), but want to concentrate on the Mac
platform specifically.  I don't have the time or resources to go into a
full-blown computer science program now, but I do have an SE/30 with a
Micron 8-bit card and Seiko monitor, some time and lots of motivation.

Where do I start?

Thanks in advance,
Jose Hulse

+++++++++++++++++++++++++++

From: [e-mail] (Jeremiah Blatz)
Date: 26 Apr 92 19:19:20 GMT
Organization: Dartmouth College, Hanover, NH

The first thing you should do -in my opinion- is join APDA. It's free,
and they'll send you a catalog of nifty stuff. To join, send e-mail to
[e-mail] (I think) and tell them you want to join (be
sure to give them your address so they can send you that nifty
catalog).

As for programming languages, try HyperCard, It's really easy, you can
probably get it for free off a BBS, and you get instant gratification.

After you get the basics down, I suggest you move up to C or Pascal. I
use Pascal, but I would reccoment C, I hear it's a far less
frustrating. As for development platforms, the standard ones are MPW
(it supports many languages), or THINK C and THINK Pascal. MPW is slow,
semi-confusing, expensive, but powerful. The THINK products are easier,
faster, and slightly less expensive, but they lack MPW's power.

Hope this helps,
Jeremiah

---------------------------

From: [e-mail] (JohnC)
Subject: cancellation (was Re: MF scrap && DialogSelect crash)
Organization: The Royal Society for Putting Things on Top of Other Things
Date: Wed, 22 Apr 1992 00:37:56 GMT

In article <[e-mail]> [e-mail] (Phil Shapiro) writes:
>In article <[e-mail]> [e-mail] (Jamie R. McCarthy) writes:
>
>   >but it's cleaner than other techniques I've seen. It removes any
>   >overhead from calling EventAvail() or GetNextEvent(), and it doesn't
>   >have the problems of calling GetOSEvent() or (shudder!) looking at the
>   >event queue directly.
>
>   Remember, this comes from a guy whose company distributes code that does
>   exactly that.  :-)  Check out AbortInQueue(), in TBUtilities.c
>   (TCL 1.1)--it walks the queue.  I must be missing something--what's so
>   bad about doing this?
>
>This is bad because it will give you false alarms about
>command-periods when your app is in the background. The low memory
>queue corresponds to the OS Event queue, which contains all events
>before the Process Manager distributes them to applications.

Which leads me to the obvious question: why in hell isn't "cancellation" a
sub-type of OSEvent, like suspend/resume and mousemoved??  There are all
sorts of localization and concurrency issues to fight with when checking for
command-period, but they are all things that the OS itself could easily
handle.  If it did so, then all a program would have to do is check for a
nice easy-to-digest cancelEvt.  This would have been a wonderful thing to
have included in the System 7 feature set.

- --
John Cavallino                  |  EMail: [e-mail]
University of Chicago Hospitals |         [e-mail]
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g+ k s++ e+ h- pv     |         Chicago, IL  60637

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 24 Apr 92 01:24:03 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail]
(JohnC) writes:
> Which leads me to the obvious question: why in hell isn't "cancellation" a
> sub-type of OSEvent, like suspend/resume and mousemoved??  There are all
> sorts of localization and concurrency issues to fight with when checking for
> command-period, but they are all things that the OS itself could easily
> handle.  If it did so, then all a program would have to do is check for a
> nice easy-to-digest cancelEvt.  This would have been a wonderful thing to
> have included in the System 7 feature set.

Actually, I'm of the same opinion. The code I posted earlier should maybe
at least be part of a library call available from MPW or Think. Have to
work on this thing...

Cheers,
Kent/DTS = Dynamic Topology Snowball

+++++++++++++++++++++++++++

From: [e-mail] (Larry Rosenstein)
Date: 24 Apr 92 21:42:30 GMT
Organization: Taligent, Inc.

In article <[e-mail]>, [e-mail]
(JohnC) wrote:
>
> Which leads me to the obvious question: why in hell isn't "cancellation" a
> sub-type of OSEvent, like suspend/resume and mousemoved??  There are all

I think this was contemplated.  I seem to recall that there were abort events in
the Phonebook Edition of Inside Mac.  (Note that in Inside Mac I, there's no
event code = 9.)

- -----
Larry Rosenstein
Taligent, Inc.
[e-mail]

---------------------------

From: [e-mail]
Subject: AppleTalk, games, speed...
Date: 22 Apr 92 04:03:02 GMT
Organization: University of Kansas Academic Computing Services

Anyone have any enlightened musings about using AppleTalk in games?  The issue
is one of speed.

I have played around with ALAP - got it working.  The problem was that too much
data was lost (collisions? - my incompetence?) and that you couldn't talk
across bridges or zones.

Recently I've been at work implementing DDP.  Not bad.  I've been getting
*fairly* reliable packets sent.  My timing experiments between a Plus and a
IIsi suggest that a packet is being sent and received at a cost of 1 Tick in
processor time.  Not bad, but I'm thinking 0.4 Ticks would be almost ideal.

Synchronization has been a problem too.  My feelings currently are - screw the
synch.  One machine will host another, and the faster machine is just going to
control the playing field.  All the various tricks I've tried have only managed
to slow the machines down to below that of the slower machine - or cause jerky
and stacato motion.

Sure the Comm Toolbox and all it's transparency would be wonderful.
Nonetheless, speed is an issue.  As is compatibility with Macs down to, say the
Mac Plus.  A reasonable "scope", i.e. access to other zones, etc. is
prefereable, but not to the severe detriment of speed.  Package integrity is
desirable too, but again ... a few lost packages for the good of the games
speed is okay.

Any ideas?

john calhoun-

+++++++++++++++++++++++++++

From: [e-mail] (Tim Endres)
Date: 22 Apr 92 14:24:21 GMT
Organization: ICE Engineering, Inc.


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] writes:
> Synchronization has been a problem too.  My feelings currently are - screw the
> synch.  One machine will host another, and the faster machine is just going to
> control the playing field.  All the various tricks I've tried have only managed
> to slow the machines down to below that of the slower machine - or cause jerky
> and stacato motion.
>
> Sure the Comm Toolbox and all it's transparency would be wonderful.
> Nonetheless, speed is an issue.  As is compatibility with Macs down to, say the
> Mac Plus.  A reasonable "scope", i.e. access to other zones, etc. is
> prefereable, but not to the severe detriment of speed.  Package integrity is
> desirable too, but again ... a few lost packages for the good of the games
> speed is okay.
>
> Any ideas?

When a networked game is being developed, you have two basic choices.
One, use the network to send information regarding the "field" to
each host for update, thus leaving all "processing" to a "server"
host. The other approach is to simply echo every user's input to each
and every host and let them all update their own field, thus making
every host a server and client. When your bandwidth is low, the second
approach is usually your only choice.

tim.


tim endres - [e-mail]  -or-  uupsi!tbomb!time
ICE Engineering, Inc. - Phone [phone] - FAX [phone]
8840 Main Street, Whitmore Lake, MI  48189
USENET - a slow moving self parody... ph

+++++++++++++++++++++++++++

From: [e-mail] (Brian Hall)
Date: 22 Apr 92 18:36:11 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

In article <[e-mail]> [e-mail] writes:
>Sure the Comm Toolbox and all it's transparency would be wonderful.
>Nonetheless, speed is an issue.  As is compatibility with Macs down to, say the
>Mac Plus.  A reasonable "scope", i.e. access to other zones, etc. is
>prefereable, but not to the severe detriment of speed.  Package integrity is
>desirable too, but again ... a few lost packages for the good of the games
>speed is okay.
>
>Any ideas?
>
>john calhoun-
>

The comm toolbox sure would be hot.  Then you would not only have code
that works over a network, but one that works over modems, across zones,
wireless, who knows!


- --
+-----------------------------------------------------------------------------+
| Brian Hall, Mark/Space Softworks                                            |
| [e-mail]; Applelink, America Online: MarkSpace                     |
+-----------------------------------------------------------------------------+

+++++++++++++++++++++++++++

From: [e-mail] (Jim Holt)
Date: 24 Apr 92 15:00:40 GMT
Organization: Motorola

In article <[e-mail]>, [e-mail] (Tim Endres) writes:
>
>
> In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] writes:
> > Synchronization has been a problem too.  My feelings currently are - screw the
> > synch.  One machine will host another, and the faster machine is just going to
> > control the playing field.  All the various tricks I've tried have only managed
> > to slow the machines down to below that of the slower machine - or cause jerky
> > and stacato motion.
> >
> > Sure the Comm Toolbox and all it's transparency would be wonderful.
> > Nonetheless, speed is an issue.  As is compatibility with Macs down to, say the
> > Mac Plus.  A reasonable "scope", i.e. access to other zones, etc. is
> > prefereable, but not to the severe detriment of speed.  Package integrity is
> > desirable too, but again ... a few lost packages for the good of the games
> > speed is okay.
> >
> > Any ideas?
>
> When a networked game is being developed, you have two basic choices.
> One, use the network to send information regarding the "field" to
> each host for update, thus leaving all "processing" to a "server"
> host. The other approach is to simply echo every user's input to each
> and every host and let them all update their own field, thus making
> every host a server and client. When your bandwidth is low, the second
> approach is usually your only choice.
>

My partner and I are developing a networked game as well.  We were discussing
the pros and cons of these methods this morning, and it seems to us that the
issue of synchronizing information becomes complicated with method 2, while
having a central database server burdens the machine doing the serving.  In
light of this, I was leaning towards method 2 using ATP.  John, your comments
are interesting to me, as we haven't gotten to the point of bench testing
performace.  Is the tradeoff of speed vs. reliability an issue ? Is DDP
that much faster than ATP ?  Also, how much info are you moving around ?

We were considering doing something like this :

while no OS events available do
   Synchronize DBs    (< 1k bytes of info)
   Visually fixup any screen discrepancies found
   Perform 1 iteration of game
end

Any comments ?


- -jh

+++++++++++++++++++++++++++

From: [e-mail]
Date: 25 Apr 92 20:23:30 CDT
Organization: University of Kansas Academic Computing Services

> My partner and I are developing a networked game as well.  We were discussing
> the pros and cons of these methods this morning, and it seems to us that the
> issue of synchronizing information becomes complicated with method 2, while
> having a central database server burdens the machine doing the serving.  In
> light of this, I was leaning towards method 2 using ATP.  John, your comments
> are interesting to me, as we haven't gotten to the point of bench testing
> performace.  Is the tradeoff of speed vs. reliability an issue ? Is DDP
> that much faster than ATP ?  Also, how much info are you moving around ?
>
> We were considering doing something like this :
>
> while no OS events available do
>    Synchronize DBs    (< 1k bytes of info)
>    Visually fixup any screen discrepancies found
>    Perform 1 iteration of game
> end
>
> Any comments ?
>
> -jh

Well, lets see.  ATP it seems is very awkward to work with.  I kept getting
various crashes just trying to get it up and going.  Hmmm.  In any event, I was
pretty unexcited about ATP even up to that point.  Since, in my game, both
machines are running symmetrically, it's *very* trashy to have one machine
doing SendRequests and the other doing, GetRequests followed by SendResponse's.
Very odd and inelegant.

DDP is quite a workhorse though - it seems.  My current strategy centers around
the two machines sending a "frame counter" with each packet.  When a machine
receives a packet, it compares it's own framecounter with that of the other
machines.  If the other machine is falling behind, the fast machine will delay
a Tick.  As well, the machines will compare the most recent framecounter
received with the previous framecounter.  Should they differ by more than 1,
you can safely assume a packet was dropped.  At this point the machine that
noticed the discrepancy will send a request for a large packet (tagged
differently) asking for all current variable settings (relevant ones of
course).

The idea is to send only mouse positions, button state, etc. between the
machines and let each machine run it's own independent game.  Because the
machines can get out of synch and since dropped packets could lead the two
machines to end up playing seperate games, the framecounter is used.

john calhoun-


+++++++++++++++++++++++++++

From: [e-mail] (Michael Peirce)
Date: 26 Apr 92 16:44:59 GMT
Organization: Peirce Software

Why not ADSP rather than DDP.  It's easier to program than DDP.

Just open a ADSP session in both directions and dump your data using
dspWrites and dspReads.

- --  Michael Peirce         --   [e-mail]
- --  Peirce Software        --   Suite 301, 719 Hibiscus Place
- --  Macintosh Programming  --   San Jose, California USA 95117
- --           & Consulting  --   voice: [phone] fax: [phone]
- --                         --   AppleLink: peirce & America Online: AFC Peirce

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 28 Apr 92 05:28:25 GMT
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] writes:

> As well, the machines will compare the most recent framecounter
> received with the previous framecounter.  Should they differ by more than 1,
> you can safely assume a packet was dropped.  At this point the machine that
> noticed the discrepancy will send a request for a large packet (tagged
> differently) asking for all current variable settings (relevant ones of
> course).

Sounds as though you need reliable communication between the two ends,
which is where I'd go along with Michael Peirce's suggestion and say "Why
not use ADSP?". DDP is good for those cases where loss of packets doesn't
require much in the way of a recovery procedure. An interesting example
would be real-time voice transmission.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00
N w im r ved m tat ng s gnature virus with built-in spelling checker.

---------------------------

From: [e-mail] (Eric A. Fisch)
Subject: General SCSI / CDROM info needed...
Date: 23 Apr 92 03:08:56 GMT
Organization: U Texas Dept of Computer Sciences, Austin TX


I am looking for the source code to any sort of working CD-ROM
driver- prefferably the audio driver. I am interested in trying
to write a CD-ROM driver and need information about what SCSI signals
cause the drive to do things like spin/search/play/eject...

Any help is appreciated... especially general scsi information.

regards,
Eric Fisch
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 26 Apr 92 00:53:44 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Eric A.
Fisch) writes:
> I am looking for the source code to any sort of working CD-ROM
> driver- prefferably the audio driver. I am interested in trying
> to write a CD-ROM driver and need information about what SCSI signals
> cause the drive to do things like spin/search/play/eject...
>
> Any help is appreciated... especially general scsi information.

DTS will have sample code out soon, soon, soon....Otherwise the developer CD
should have snippets dealing with CD-ROM handling.


Cheers,
Kent

---------------------------

From: [e-mail] (Andrew E Page)
Subject: How do you do a simple output window in MacApp?
Date: 23 Apr 92 18:19:47 GMT
Organization: The World Public Access UNIX, Brookline, MA


   All I want is a window that I can printf or << to.  Is there
some simple way of doing this?


- --
Andrew E. Page CTO(Warrior Poet)|   Decision and Effort The Archer and Arrow
DSP Ironworks                   |     The difference between what we are
Macintosh and DSP Technology    |           and what we want to be.

+++++++++++++++++++++++++++

From: [e-mail] (Eric Berdahl)
Date: 23 Apr 92 23:05:25 GMT
Organization: Taligent, Inc.

In article <[e-mail]>, [e-mail] (Andrew E Page) writes:
>    All I want is a window that I can printf or << to.  Is there
> some simple way of doing this?

Andrew,

If you are using MacApp 2.0, build a debug version of you application.  All
stdout and cout are both directed to the transcript window that you can open
from the debug menu.

If you are using MacApp 3.0, you donUt have to build a debug version of your
application, but you do need to get a copy of SourceBug and have it running.
Note: this does not mean that you need to be SourceBugging you application!!
Just have SourceBug running at the same time that your MacApp 3.0 app is
running.  In this configuration, stdout and cout are directed to a transcript
window managed by SourceBug (SADE might do this, too, but I don't know for sure.
 SourceBug I know for sure.)

Hope this helps,
- --
Eric Berdahl                                 MADA President
Internet: [e-mail]          AppleLink: BERDAHL
#include <StdDisclaimer.h>
This is a freeware signature.  What do you expect for nothing?

+++++++++++++++++++++++++++

From: [e-mail] (Greg Trimper)
Date: 24 Apr 92 07:30:59 GMT
Organization: Enterprise Data Systems Incorporated, Appleton WI

[e-mail] (Andrew E Page) writes:


>   All I want is a window that I can printf or << to.  Is there
>some simple way of doing this?

What I discovered a few weeks ago was the S I O W Build... option,
which is a 32k Simple IO window.  If you build for that type
of app, you should have no prob.


Greg Trimper   [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Andrew E Page)
Organization: The World Public Access UNIX, Brookline, MA
Date: Fri, 24 Apr 1992 15:00:30 GMT

In article <[e-mail]> [e-mail] (Greg Trimper) writes:
>[e-mail] (Andrew E Page) writes:
>
>
>>   All I want is a window that I can printf or << to.  Is there
>>some simple way of doing this?
>
>What I discovered a few weeks ago was the S I O W Build... option,
>which is a 32k Simple IO window.  If you build for that type
>of app, you should have no prob.

  Yes, but as the subject line said, I'm working with MacApp.  Is ther
a way of adding SIOW windows within MacApp 3.0?



- --
Andrew E. Page CTO(Warrior Poet)|   Decision and Effort The Archer and Arrow
DSP Ironworks                   |     The difference between what we are
Macintosh and DSP Technology    |           and what we want to be.

+++++++++++++++++++++++++++

From: [e-mail] (Mark Lanett)
Date: 23 Apr 92 20:40:07 GMT
Organization: University of Illinois at Urbana

[e-mail] (Andrew E Page) writes:

>   All I want is a window that I can printf or << to.  Is there
>some simple way of doing this?

There are several ways, depending on what you want the output for.

Debugging: MacApp 2.0 has a built-in Transcript window. In MacApp 3.0,
stdout is redirected to SADE or SourceBug (the release notes discuss how
to teach SADE to accept it).

Just to display messages (i.e., no scrollback): A TEView isn't desirable here
because it keeps the history. I'd instead check out issue 9 (or 10?) of
develop, which implements a message window using the CTB. You could also
write some CTB classes while you are at it and donate them to the net :-)

With scrollback: You could add scrollback to the CTB window or use a TEView.
I use a TEView, but under 3.0 I've never gotten it to update quite properly
(under 2.0 it was fine). It doesn't update the portion that scrolled while
printing, so I essentially call ForceRedraw after each print call, making
it *rather* slow.

TTEView* gTranscript = nil;

#pragma trace off
void DebugPrint (char * buffer, Boolean redraw, Boolean select = false)
{
        if (gTranscript) {
                PrintIntoTEView (buffer, gTranscript, redraw);
                gTranscript->GetWindow ()->Open ();
                gTranscript->SynchView (true);
                if (select) gTranscript->GetWindow ()->Select ();
                gTranscript->Update ();                 // does the redraw
        }
#if qDebug
        printf ("%s", buffer);
#endif qDebug
}

#pragma trace off
void Debug_Print (char * format, ...) // acts just like printf
{
        char temp [255];
        va_list arglist;
        va_start (arglist, format);
        vsprintf (temp, format, arglist);
        va_end (arglist);
        DebugPrint (temp, true, false);
}

#pragma trace off
void PrintIntoTEView (char * text, TTEView * aTE, Boolean redraw)
{
        TESetSelect (32767, 32767, aTE->fHTE); // put selection at end
        Handle itsText = aTE->fText; // what is in there already
        long size = GetHandleSize (itsText); // how long is it (handle is always full so handle size == # of chars)
        long add = strlen (text); // how long will it be after we print

        if (add + size > aTE->fMaxChars) // cannot exceed its size limit
                return; //Failure (minErr, 0); // should prob. do something here

        TEInsert (text, add, aTE->fHTE); // print it

        if (GetHandleSize (itsText) < size+add) // if it didn't print there's been a problem with growing the handle
                FailNIL (nil);

    // these are the magic lines that just refuse to update properly
        aTE->fSpecsChanged = true; // mark it as needing to recalculate
        aTE->RecalcText ();
        aTE->SynchView (true); // let SynchView updateI
        if (redraw) {
                aTE->ForceRedraw (); // I suggest you experiment with these
               // aTE->Update(); // two lines
        }
}
- --
Mark Lanett, Software Tools Group, NCSA; [e-mail]; NCSA.STG (AppleLink)

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 26 Apr 92 00:51:48 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Andrew E Page) writes:
>    All I want is a window that I can printf or << to.  Is there
> some simple way of doing this?

MacApp 2.0 had in debug mode a nice output window which handled printf,
cout or writelns. This code was moved to the SourceBug debugger in
MacApp 3.0, i.e. if SourceBug is up and running, it will present
cout statements in a window which is automagically opened.

Still, if you are keen to get a similar window in your application,
check out the TTranscriptView unsupported class, available in the
same folder as MacApp 3.0 on the ETO.

Cheers,
Kent

---------------------------

From: [e-mail] (Peter Hickman)
Subject: Datagloves
Date: 23 Apr 92 15:19:25 GMT
Organization: University of Sussex

Does anyone have any pointer to connecting up a Nintendo powerglove up to a
Mac? I seem to recall an article somewhere (possibly Byte) about this. Has
someone a better memory than I about this.
- --
- --------------------------------------- [e-mail] ------------
      "More beer, more shouting, resistance is useless" - USTA bars

+++++++++++++++++++++++++++

From: [e-mail] (Owen M. Hartnett)
Date: 26 Apr 92 04:53:05 GMT
Organization: Brown University Department of Computer Science

Try Goldbrick Systems in Cambridge MA (don't know their number).  They make
a Nintendo Power Globe -> Mac interface with some software.  Seemed to work
really well when they demonstrated for the BCS techgroup.

- -Owen

Owen Hartnett                [e-mail]
"FAITH, n. Belief without evidence in what is told by one who speaks
        without knowledge, of things without parallel."
            -Ambrose Bierce - The Devil's Dictionary

+++++++++++++++++++++++++++

From: [e-mail] (Michael A. Kelly)
Organization: University of Oregon Computer and Information Sciences Dept.
Date: Sun, 26 Apr 1992 08:03:41 GMT

In article <[e-mail]> [e-mail] (Owen M. Hartnett) writes:
>Try Goldbrick Systems in Cambridge MA (don't know their number).  They make
>a Nintendo Power Globe -> Mac interface with some software.  Seemed to work
>really well when they demonstrated for the BCS techgroup.

It's Transfinite Systems Company, Inc.
P.O. Box N, MIT Branch Post Office
Cambridge, MA  02139 USA
Tel: [phone]
AppleLink: D2002

Mike.
- --
_____________________________________________________________________________
Michael A. Kelly                                         University of Oregon
[e-mail]                             Computer Science Department
_____________________________________________________________________________

+++++++++++++++++++++++++++

From: [e-mail] (Thomas A. Creedon)
Date: 24 Apr 92 22:31:22 GMT
Organization: Oregon Hearing Research Center

In article <[e-mail]>, [e-mail] (Peter Hickman) writes:
>
> Does anyone have any pointer to connecting up a Nintendo powerglove up to a
> Mac? I seem to recall an article somewhere (possibly Byte) about this. Has
> someone a better memory than I about this.
> --


If I recall correctly the info-mac archives at sumex contained an article
on that subject.  Good luck!

Toodle-loooooo.......
Thomas

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 26 Apr 92 00:54:54 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail]
(Peter Hickman) writes:
>
> Does anyone have any pointer to connecting up a Nintendo powerglove up to a
> Mac? I seem to recall an article somewhere (possibly Byte) about this. Has
> someone a better memory than I about this.

The electronic 'recipe' has been posted on sci.virtual now and then. I should
have it somewhere, but I didn't find it in my current mess of my electronic
archives.

Cheers,
Kent

+++++++++++++++++++++++++++

From: [e-mail] (Juri Munkki)
Date: 26 Apr 92 19:49:34 GMT
Organization: Helsinki University of Technology, Finland

In article <[e-mail]> [e-mail] (Kent Sandvik) writes:
>In article <[e-mail]>, [e-mail]
>(Peter Hickman) writes:
>>
>> Does anyone have any pointer to connecting up a Nintendo powerglove up to a
>> Mac? I seem to recall an article somewhere (possibly Byte) about this. Has
>> someone a better memory than I about this.
>
>The electronic 'recipe' has been posted on sci.virtual now and then. I should
>have it somewhere, but I didn't find it in my current mess of my electronic
>archives.

Someone in sci.virtual-worlds is working on a serial port device that would
support the Sega 3D glasses and the PowerGlove in hires mode. The circuit
diagram that I have now only supports the joystick mode. Byte also handled
only the joystick mode.

Unless the serial port device (a 68HC11 computer really) is too expensive,
I'll probably be buying one for my PowerGlove.

The hires mode of the PowerGlove has been fairly well documented, but so
far no one has connected it directly to a Mac. (PC and Atari software
exists, but I guess they use the parallel ports.) Don't ask me how to do
it: I haven't saved the articles.

   ____________________________________________________________________________
  / Juri Munkki        /  Helsinki University of Technology   /  Wind  / Project /
 / [e-mail]  /  Computing Center Macintosh Support  /  Surf  / Arashi  /
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---------------------------

From: [e-mail] (Casgrain Philippe)
Subject: CountAppFiles doesn't work
Date: 24 Apr 92 14:51:33 GMT
Organization: Universite de Montreal


        Dear net friends,

        I am working on a small drag-and-drop app, and I need to know
the number of files the user has selected in the finder to drop on my app.
        Now, I read in IM-II that I can call 'CountAppFiles' to do this,
but even if I drop a large number of files on my app, the 'count' variable
always contains zero.

        I don't think I'm doing anything non-kosher; I tried initializing
the Toolbox before and after CountAppFiles, to no avail.

        If you have stumbled on this problem, or have already written a
drag-and-drop app, do you have an idea of what's going on?

        Thanks,
        Philippe
        [e-mail]

P.S. Thanks to the people who answered my previous posting; they were very
        helpful.

+++++++++++++++++++++++++++

From: [e-mail] (Steve Herman)
Organization: Boeing Computer Support Services (BCSS)
Date: Fri, 24 Apr 1992 17:03:14 GMT

In article <[e-mail]>,
[e-mail] (Casgrain Philippe) writes:
>         Dear net friends,
>
>         I am working on a small drag-and-drop app, and I need to know
> the number of files the user has selected in the finder to drop on my app.
>         Now, I read in IM-II that I can call 'CountAppFiles' to do this,
> but even if I drop a large number of files on my app, the 'count' variable
> always contains zero.

    Is your application Apple Event aware?  If so, CountAppFiles always seems
to return zero (although I was never able to find this documented anywhere).
You should look for the "Open Documents" apple event and process the event in
a manner similar to the example on page 6-34 of Inside Mac Volume VI.


Good Luck,

Steve

- -------------------------------------
Steve Herman
"Happiness is just a 'Flaming Moe' away"
- -------------------------------------

---------------------------

From: [e-mail] (Richard Eames)
Subject: TCL Mailing List?
Date: 23 Apr 92 23:58:17 GMT
Organization: Apple Computer Inc., Cupertino, CA

I have heard there is some sort of TCL mailing list.  How does one get added?

Thanks,

Rick Eames
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Daryl Spitzer)
Date: 24 Apr 92 15:19:27 GMT
Organization: MIND LINK! - British Columbia, Canada

> I have heard there is some sort of TCL mailing list.  How does one get added?

There seems to be no specific TCL discussion list so am creating one here
at Brown.  At this time it will be an unmoderated list for the discussion
of the Think Class Library for C and Pascal (seems little need to restrict
it).

The list will be

     [e-mail]

Requests should be made to

    [e-mail]

The FTP archive will be at

     ftp.brown.edu:/pub/tcl

WAIS indices of the list and archive materials will be at

     (:source
          :database-name "tcl-talk"
          :ip-name "wais.brown.edu" )

     (:source
          :database-name "tcl-archive"
          :ip-name "wais.brown.edu" )

- -- Andrew Gilmartin
   Computing & Information Services
   Brown University

   [e-mail]

- --
- -------------------------------------------------------------------
 [e-mail]     "Life isn't just, life just is."
         [e-mail]              -- Me  (I think.)
       [e-mail]
- -------------------------------------------------------------------

+++++++++++++++++++++++++++

From: [e-mail]
Date: 24 Apr 1992 20:31:28 GMT
Organization: Brown University

>I have heard there is some sort of TCL mailing list.  How does one get added?

THINK CLASS LIBRARY DISCUSSION LIST

The Think Class Library discussion list is for those interested in
using Symantec's Think C and Think Pascal object-oriented class
library for Macintosh. Discussion topics include

*    class usage, design, and implementation

*    TCL bug reports, work-arounds, and fixes

*    TCL application development techniques

*    TCL development aids

Mail to the discussion list should be sent to

     [e-mail]

The discussion is archived and WAIS searchable at "(:source :database-
name tcl-talk :ip-name wais.brown.edu)".


THINK CLASS LIBRARY REQUESTS

All requests should be made to

     [e-mail]

Use this address to make changes to your subscription (subscribing,
suspending, unsubscribing, etc.) and for submissions to the archive
(see below). I really can't handle requests for materials from the
archive; I hope to soon have an automatic listserv doing this for me
(recommendations of good, simple software is appreciated).

Expect a 36 hour turnaround time for most requests.


THINK CLASS LIBRARY ARCHIVE

In addition to the discussion list, there is a ftp accessable archive at

     ftp.brown.edu:/pub/tcl

Login as anonymous; please use your email address as the password.

The archive is organized by contributor and category. The current
organization is

contributors   Directories of contributors and their contributions.
               All other directories have their materials linked from
               here.

bugs           Bug notices with work-arounds or fixes when known. Bug
               filenames have the form "<class>-<method>.bug.<index>":
               Bugs affecting the whole class do not have a method
               specifier.

classes        Contributor classes and their documentation. Class
               filenames have the form "<class>.class.<index>".

core           Changes to the TCL core classes. Core change filenames
               have the form "<class>-<method>.core.<index>". Changes
               affecting the whole class do not have a method
               specifier.

doc            Tutorials, style guides, etc.

examples       TCL technique examples.

misc           Useful TCL stuff.

new            Links to all new files added to the archive in the last
               month.

tcl-talk       Archive of the [e-mail] discussion list. The
               archive currently has one file per message organized by
               year. Message filenames have the form
               "<date>.talk.<index>".

Submissions to the archive should be mailed to tcl-request or ftped to
ftp.brown.edu:/incoming/tcl with accompanying mail to tcl-request. Encode
all submissions in BinHex 4.0 format (aka HQX) and include a descriptive
header (for example, the text of the readme file). Please do not
redistribute Symantec's TCL source.


WHAT IS WAIS?

WAIS is an emerging Internet protocol for the searching of a
distributed set of databases. The protocal is based upon the ANSI
draft Z39.50. WAIS stands for Wide Area Information Servers and
orginated as a project  between Thinking Machines, Apple, and Dow
Jones. Thinking Machines has been promoting WAIS by providing a free
server and client software. The Macintosh client, WAIStation, was
written in TCL by a subscriber to TCL-Talk. Anyway, the software is
available from think.com:/wais as is more information.

When using WAIStation all you need to know is that you can find out
what databases are available at Brown University by creating a new
Source withdatabase name INFO, address wais.brown.edu, and port 210.

4/17/92

- --
Andrew Gilmartin
Computing & Information Services
Brown University

[e-mail]


---------------------------

From: [e-mail] (Jeffrey Verdegan)
Subject: Weird problem with TEIdle/Blinking cursor
Date: 24 Apr 92 18:53:20 GMT
Organization: College of Engineering, Univ. of Wisconsin-Madison

Okay.  I'm confused.  My app was working (more or less) with THINK C 4.0.
Now I'm in the process of upgrading to 5.0.2, and I'm having a wee bit of
trouble.  TEIdle doesn't seem to be working.  When I start the app, the
blinking insertion bar either is or isn't there, but it doesn't blink. After
I type or something (don't remember exactly how it happens), it disappears.
If I click and hold the mouse button, the insertion bar shows up.  When I
release the mouse, the insertion bar goes away.  Some combination of typing,
creating a new edit window, switching to THINK's debugger and back to my app
will eventually cause it to start blinking, but I haven't been able to figure
out what exact sequence does it, or whether it's the same each time.

I call TEIdle at least once through my event loop, oft times more.  Anybody
have any idea what I should look for?  Are there any known problems with 5.0.2
and TEIdle, etc.?  As I've been porting, I've been rearranging some things to
try to clean up the code and compartmentalize things a bit more, so it may
be something I did, but I don't see anything unkosher, and I'm not sure exactly
what I should be looking for anyway.

Tons o' thanks for any help!

Jeff


- ----------

Jeff Verdegan
University of Wisconsin-Madison
Computer-Aided Engineering Center
[e-mail]
[phone]

+++++++++++++++++++++++++++

From: [e-mail] (Jeffrey Verdegan)
Date: 24 Apr 92 20:16:17 GMT
Organization: College of Engineering, Univ. of Wisconsin-Madison

In article <[e-mail]> I write:

>Okay.  I'm confused.  My app was working (more or less) with THINK C 4.0.
>Now I'm in the process of upgrading to 5.0.2, and I'm having a wee bit of
>trouble.  TEIdle doesn't seem to be working.  When I start the app, the

...and a bunch more drivel about the insertion bar not blinking.  I figured
it out.  It was my fault.  As I was moving stuff around in the interest of
clean code, I moved the definition of the variable inForeGround, but I didn't
copy the initialization over, so my app thought is was in the background for
all intents and purposes, almost.  There was just enough of it that knew it
was in the foreground to *look* like it was in the foreground, so it took a
while to even consider looking at that.

Oops.  Color me sheepish.  <8)



- ----------

Jeff Verdegan
University of Wisconsin-Madison
Computer-Aided Engineering Center
[e-mail]
[phone]

---------------------------

From: [e-mail] (Matthew Hall)
Subject: Color picts drawing in B$W. HELP!
Date: 25 Apr 92 22:38:40 GMT
Organization: Oberlin College Computer Science

Hello-
    I have a problem. I'm drawing color pictures in a color window
with a palette that I loaded from a resource. (a grey scale and a red
blue ramp).  I draw the image, open a picture, copybits it to itself,
close the picture and save it in a resource file.
    Now, naievely expecting that if I use a color window with the
same palette as I drew the picture in, and load the resource and draw
it, I should get my nice beautiful picture in full glory.  Instead, I
only get a black and white picture where everything is black except
the parts that were strictly white in the color image.
    If I don't set the palette in my window, the picture draws in
an approximation to the original colors, but definitely not the nice
smooth greyscales that I got before.
    Looking with lightsbug at the picture data, I find, first of
all, that some of the things IMV says should be 0 or -1, just aren't,
such as the pmTable field (set to the same as ThePorts pixmap), and
the ctseed field of the color data, but
that the color information contains 256 colors and looks like a
greyscale.
    WHY IS THIS HAPPENING?  More specifically, how do I use the
greyscales that I want?  I have code for storing pixmaps in a data
file, but I would really like to use PICTs, since resources are
handier, and picture does automatic compression.  So please, can
someone tell me what is going on and how to stop it.

- -matt hall

P.S.  I remember seeing a thread here that you have to make sure that
CtSeeds of 2 cluts are equal for copybits to copy images without
translation.  Do I have to parse the picture defs of all my pictures
to find the appropriate ctseed and change my windows ctseed to it?
That would be a pain.

- --


- -------------------------------------------------------------------------------
Matt Hall.    [e-mail]  OR  [e-mail]
              (216)-775-5805 (That's a Cleveland Area code. Lucky Me)

"If a man comes up to you and says:
    'A dog just carried away your ear.'
Do you run after the dog, or search first for your ear?" - Moon over Morocco


+++++++++++++++++++++++++++

From: [e-mail] (Matthew Hall)
Date: 27 Apr 92 03:31:04 GMT
Organization: Oberlin College Computer Science

A little while ago I wrote:
>
>   P.S.  I remember seeing a thread here that you have to make sure that
>   CtSeeds of 2 cluts are equal for copybits to copy images without
>   translation.  Do I have to parse the picture defs of all my pictures
>   to find the appropriate ctseed and change my windows ctseed to it?
>   That would be a pain.
>

It doesn't work, I don't think.  Please help soon, I won't have
internet access in 2 weeks.

thank you
- -matt hall

- --


- -------------------------------------------------------------------------------
Matt Hall.    [e-mail]  OR  [e-mail]
              (216)-775-5805 (That's a Cleveland Area code. Lucky Me)

"If a man comes up to you and says:
    'A dog just carried away your ear.'
Do you run after the dog, or search first for your ear?" - Moon over Morocco


---------------------------

End of C.S.M.P. Digest
**********************